Should an error be thrown on the AIContent related return types? If we go by the intent expressed by dsp and others, and Content SHOULD be present for backwards compatibility, but (the part missing right now) MUST not differ from StructuredContent if it is - then there is no possible way to do with these.

It would be a breaking change, so probably best to wait with that until the spec is actually updated. Just wanted to mention that as pointed out in the issue, this is only a fix for the string case. I think that's the one most likely to cause trouble on actual production servers, so I still think it's worth fixing this one in isolation. Setting the attribute property to true for an AIContent or CallToolResult returning tool is a really exotic edge-case (to be fixed with the spec change imo - at the same time as any introduced schema validation requirements).

For consideration:
Requiring the Content to match the structuredContent would be an issue if trying to target OpenAIs new Apps SDK.
There structuredContent and Content explicitly do not have to match the same schema.

https://developers.openai.com/apps-sdk/build/mcp-server

a sample response from their "Structure the data your tool returns" paragraph:

return {
      structuredContent: {
        columns: board.columns.map((column) => ({
          id: column.id,
          title: column.title,
          tasks: column.tasks.slice(0, 5) // keep payload concise for the model
        }))
      },
      content: [{ type: "text", text: "Here's your latest board. Drag cards in the component to update status." }],
      _meta: {
        tasksById: board.tasksById, // full task map for the component only
        lastSyncedAt: board.lastSyncedAt
      }
    };

For consideration:
Requiring the Content to match the structuredContent would be an issue if trying to target OpenAIs new Apps SDK.
There structuredContent and Content explicitly do not have to match the same schema.

https://developers.openai.com/apps-sdk/build/mcp-server

a sample response from their "Structure the data your tool returns" paragraph:

return {
      structuredContent: {
        columns: board.columns.map((column) => ({
          id: column.id,
          title: column.title,
          tasks: column.tasks.slice(0, 5) // keep payload concise for the model
        }))
      },
      content: [{ type: "text", text: "Here's your latest board. Drag cards in the component to update status." }],
      _meta: {
        tasksById: board.tasksById, // full task map for the component only
        lastSyncedAt: board.lastSyncedAt
      }
    };

There is some discussion around this at the protocol governance level. I expect we'll see a change where they do not have to be the same.

The current requirements of the Apps SDK will cause some MCP SDKs to warn/fail, and isn't fully spec compliant, even if one can argue the spec doesn't forbid the discrepancy, this is because the assumption was they either matched or only one was provided.

Another interesting aspect is that the Apps SDK sends the unstructured text result to the model and uses the structured results for host specific processing. Implementing something similar on the client host in the C# SDK is awkward, as the convenience MEAI tool mappers assume the structured output should be sent to the model.

So the change in the spec should arguably also be accompanied by a change to this behavior to prioritize the unstructured output if supplied. Or at least make it easily configurable.

Another interesting aspect is that the Apps SDK sends the unstructured text result to the model and uses the structured results for host specific processing. Implementing something similar on the client host in the c# SDK is awkward, as the convenience MEAI tool mappers assume the structured output should be sent to the model.

From what i understand from the OpenAI Apps SDK docs is that both the structured AND the unstructured content are provided to the model:
Your component receives all three fields, but only structuredContent and content are visible to the model.

Another interesting aspect is that the Apps SDK sends the unstructured text result to the model and uses the structured results for host specific processing. Implementing something similar on the client host in the c# SDK is awkward, as the convenience MEAI tool mappers assume the structured output should be sent to the model.

From what i understand from the OpenAI Apps SDK docs is that both the structured AND the unstructured content are provided to the model: Your component receives all three fields, but only structuredContent and content are visible to the model.

Ah yes - but I am not sure all of that is placed in the actual tool response content part. Either way, we're now in a situation where it is client dependent which fields go where and how, which complicated things a lot when one wants to write servers that are generic and work with multiple clients.